1. Field of the Invention
The present invention relates to the field of object-oriented programming for building component-based distributed business applications using the Enterprise JavaBeans(trademark) architecture and, more particularly, to a method and system for running application code originally developed as simple Java beans, in an Enterprise JavaBean (EJB) environment, without modifying the original application code.
2. Description of the Related Art
The Java programming system is an object-oriented system utilizing the Java programming language and is particularly valuable for use in a distributed environment such as the Internet. The convergence of the electronic entertainment and consumer industries with data processing exponentially accelerated the demand for wide ranging communications distribution channels, and the explosion of the World Wide Web propelled the Java system and language to the forefront of computer technology. For details and background with respect to the Java system, reference may be made to a typical text, xe2x80x9cJust Javaxe2x80x9d, Second Edition, Peter van der Linden, Sun Microsystems, 1997. Throughout the 1990s, thousands of programs were written to exploit the abilities of the Java system and language. A specific example of one such program is the IBM product called xe2x80x9cHost Publisherxe2x80x9d, discussed in more detail below.
The Java programming system involves the definition, creation, and use of xe2x80x9cobjectsxe2x80x9d. These objects are software entities, comprising data elements (called xe2x80x9cpropertiesxe2x80x9d or xe2x80x9cattributesxe2x80x9d), and xe2x80x9cmethodsxe2x80x9d which manipulate the data elements. The Java programming language can be used to create complete applications that can be run on a single computer or be distributed among servers and clients in a network.
The JavaBeans(trademark) API (Application Programmer""s Interface) is a widely used API in Java programming. A Java bean is a basic Java object which adheres to certain naming conventions for its methods and properties; namely, Java beans have properties (i.e., data fields) and provide access to those properties via xe2x80x9csetterxe2x80x9d and xe2x80x9cgetterxe2x80x9d methods. Generically known as xe2x80x9caccessorsxe2x80x9d, setters modify the value of a data field and getters obtain the value of a field from a location identified in the bean. Java beans and their common properties and functions are described in detail in the text, xe2x80x9cJava in a Nut Shell,xe2x80x9d 2nd. Edition by David Flanagan, published by O""Reilly and Assoc. Inc., California, 1997, particularly Chapter 10, pp. 178-189.
The goal of the Java bean model is its commonality and interoperability with other beans to form a combination component or bean, and the Java bean, like Java itself, was widely accepted in the industry and was (and is) utilized to develop and enhance thousands of computer programs. Beans have defined common interfaces and thus, when beans are connectable via their common interfaces, the interfacing beans may export to each other 1) properties or attributes, 2) events and 3) methods.
IBM""s xe2x80x9cHost Publisherxe2x80x9d is an example of a program that was developed based on the Java bean model. It is a solution, specifically designed for building Web applications, that extracts information from xe2x80x9clegacyxe2x80x9d terminal-oriented applications based on 3270, 5250, and VT data streams, as well as relational databases. A legacy application is an application based on languages, platforms, and/or techniques earlier than the currently-available technology. Legacy applications present a significant challenge to enterprises, in that the legacy applications often perform operations critical to the enterprise and must be kept running while being converted to the current technology.
For terminal-oriented applications, Host Publisher provides tools for building Java beans that can extract information from those applications without modifying the applications themselves. Using Host Publisher, a legacy application, e.g., one based on a 3270 data stream, can be navigated through its various screens by a Host Publisher Java bean known as an xe2x80x9cIntegration Objectxe2x80x9d or xe2x80x9cIOxe2x80x9d.
FIG. 1 illustrates a typical Java bean environment according to the prior art. A client Java application/JSP 100 (a Java Server Pages (JSP) page is an example of a client Java application) creates instances of Java beans JB101, JB102, JB103 . . . , Jbn. The client Java application/JSP 100 invokes the setter methods of Java bean JB101 to provide the xe2x80x9cinput propertyxe2x80x9d values. Input properties could be, for example, the last and first name of a person whose directory information is being accessed by running a Host Application 130. Next, the client Java application/JSP 100 invokes the xe2x80x9cexecution methodsxe2x80x9d of the Java bean JB101 to direct it to perform the required functions with regard to the Host Application 130. An execution method is typically an instruction or instruction set that directs the Java bean to run a xe2x80x9cmacroxe2x80x9d that would run the Host Application 130. This execution of the Host Application 130 causes data to be retrieved from a legacy data source or program and presented on a screen, which data is then extracted and placed in the output properties of the Java bean. In the context of the example discussed above, the output data could be specific information from the directory of the person identified by the input properties; this information is called xe2x80x9coutput properties.xe2x80x9d Processing control is then returned to the Client Java application/JSP 100, which invokes the getter methods of the Java bean JB101 to retrieve the data in the output properties.
The information from various screens is extracted in this manner and can be can be used to generate a Web page dynamically. The Web page can then be presented to a browser user who is not familiar with the 3270 application""s user interface. This enables legacy application rejuvenation, and allows the investment in the existing application to be exploited for competitive advantage. Host Publisher has been an extremely useful and successful product and is utilized by many for building dynamic Web pages based on legacy applications.
In connection with Sun Microsystems"" delivery of the Java2 Enterprise Edition (J2EE) platform in December of 1999, a technology known as EJB (Enterprise Java Bean) technology was developed, and EJB support is the cornerstone of the J2EE platform. Despite its name, an EJB is not a Java bean; it is an industry standard architecture for running server-side business logic, providing additional benefits of locatability in a network, and scalability. Among other improvements, EJB technology reduces time to market for enterprise-class applications. J2EE and EJB""s have received widespread industry support and growing customer acceptance and increased investment focus has been placed on EJB and J2EE technology by the industry. A problem exists, however, since many products, such as Host Publisher, are based on Java bean technology and will not readily function with EJB technology.
One method of enabling a Java bean (such as a Host Publisher IO) to run in an EJB environment involves a very cumbersome process of rewriting and compiling each Java bean to follow EJB coding conventions and use supporting APIs, i.e., creating a custom EJB that performs the same functions as the Java bean, and repeating this step for each Java bean. For example, when attempting to utilize a Host Publisher IO to screen-scrape a program operating in an EJB environment, the IO, which as mentioned above, is a Host Publisher-specific Java bean, cannot run in an EJB environment. FIG. 2 is a block diagram illustrating this rewriting and compiling process. Referring to FIG. 2, a series of Java Beans JB201, JB202, JB203 . . . , JB2n are shown. Since these Java beans will not function in an EJB environment, the code of each Java bean JB201, JB202, JB203, . . . , JB2n is rewritten following EJB coding conventions and recompiled using the standard Java compiler. This can be accomplished by a Java programmer using standard Java tools. Thus, JB201 is rewritten and compiled as EJB 216; JB202 is rewritten and compiled as EJB 217; JB203 is rewritten and compiled as EJB 218; . . . , and JB2n is rewritten and compiled as EJB 2n. 
FIG. 3 illustrates the operation of the rewritten and compiled Java beans, now EJB""s, in an EJB environment. As shown in FIG. 3, once the rewriting/compiling process is complete for each Java Bean, the respective EJB""s can be deployed in an EJB container 315 of an EJB server 310 in a known manner. The EJB""s are then available for use as needed to perform the same functions on a Host Application 330 as those of the Java beans.
While the above-described rewriting/compiling process works adequately, it is time consuming. Further, typical EJB containers can only hold a relatively small number of EJB""s and still remain effective. As the number of unique EJBs in the container increases, the amount of processing required to run any one EJB can increase exponentially, thereby degrading performance and scalability.
Another method of enabling a Java bean to run in an EJB environment is to, rather than rewriting and compiling the Java bean as an EJB, instead, write a new EJB for each Java bean which will, during operation, create an instance of the original, unmodified Java bean and drive the getters and setters and execution methods of the newly-created Java bean instance. While this has the advantage of not having to change the original Java bean (since it is used xe2x80x9cas isxe2x80x9d by the EJB), this is still a time-consuming process and has the same disadvantage of producing a potentially large number of unique EJBs, one per unique Java bean, which would not run efficiently in typical EJB containers.
In both of the above methods of creating unique EJBs, one per unique Java bean, the method revolves around creating an EJB that provides the same properties and Java execution methods as the original Java bean. That is to say, EJB X would have the same getter/setter and execution methods as Java bean X whose functionality it is to perform.
While the above-described methods work adequately, they may not work well for an EJB environment. In particular, for those Java beans which contain a large number of input and/or output properties, requiring a separate invocation of the EJB""s setter method for each input property value and/or getter method for each output property value would be inefficient and excessively network-intensive, given the apparent client/server nature of the EJB architecture.
In both the above methods of creating unique EJBs, one per original Java bean, there is a further requirement to change the client Java application or the JSP to invoke the unique EJB instead of the original Java bean. In addition to being time-consuming and cumbersome, the skill required to change the client code to invoke the EJB is specialized and may not be readily available.
Accordingly, a need exists for a method for easily and efficiently enabling a client Java application, which uses the functions provided by a Java bean, to perform the same functions in an Enterprise JavaBeans environment, thus reaping the benefits of EJB technology.
The present invention provides a method for enabling the operation of object-oriented programs based on Java bean technology in an EJB environment. It is a method and system for running application code originally developed as simple Java beans, in an Enterprise Java Bean (EJB) environment, without modifying the original application code. This is accomplished by running one or more original Java beans in an EJB environment based on control from an external program, using at least the steps of defining a single generic EJB and installing the single generic EJB in an EJB container; generating EJB support code for each of the one or more original Java beans, and executing the EJB support code to drive the generic EJB to perform the functions of the one or more original Java beans in the EJB environment
In a preferred embodiment, the step of generating EJB support code comprises at least the steps of: introspecting each of the one or more original Java beans to determine their setter/getter and execution methods; generating, for each of the one or more original Java beans, an access bean class having the same signature (the same input and output properties and execution methods) as the original Java bean class; generating, for each of the one or more original Java beans, a properties class containing input and output properties matching those of the original Java bean class, and thus, the access bean class; generating, for each of the one or more Java beans, a helper class that subclassess the original Java bean; and setting a static variable in each of the properties classes to correlate it with its associated helper class.
In a more preferred embodiment, the external program is modified so that for each of the original Java beans it was using, it drives the access bean instead of the original Java bean, and the execution step comprises at least the steps of: creating an access bean object (an instance of a class) and a properties object for the original Java bean; setting the input properties of the properties object; and invoking the execution method of the access bean; creating an instance of the generic EJB, calling the generic EJB""s business method, and passing to it the properties object containing the input property values of the access bean which corresponds to the input property values of the original Java bean; the generic EJB creates the helper object corresponding to the original Java bean using Java reflection; passing to the helper object the properties object passed to the generic EJB""s business method; and calling the main execution method of the helper object; the helper object executing the original Java bean which is an instance of its parent class by using the original Java bean""s input properties from the corresponding properties object that was passed to it by the generic EJB; the helper object creating a second properties object after the Java bean execution is complete, the second properties object containing the original Java bean""s output properties; passing the second properties object back to the generic EJB when the main execution method of the helper object completes; passing the second properties object from the generic EJB, to the corresponding access bean object when the EJB business method execution completes; and saving the second properties object and returning control to the external program.